Obtaining the traffic matrix of a data network is often considered as the first step in a variety of operational management or planning tasks. The traffic matrix describes who is using the network by sending how much traffic between different points in the network. If the traffic matrix is understood accurately, it is possible, for example, to predict the impact of topology changes or study the behaviour of the network under the failure of components. The traffic matrix is also required when introducing traffic engineering (TE), explicitly controlling how traffic is moved through the network.
Considering its importance it may come as a surprise that there appear to be few known ways of extracting a traffic matrix from the actual network:
External Interface Capture
One method to obtain the complete traffic matrix is to collect data at all ingress/egress points. This provides all relevant information, without affecting core network performance. Clearly, the resource consumption of the edge devices will increase, and it may be prohibitively expensive to install data collectors for all edge interfaces. Transfer of the collected information to a central analysis point also is an issue. This method needs strong data aggregation in each access location in order not to swamp the network with Netflow-generated traffic. The number of concentrator devices required may be very large.
Zero Bandwidth Tunnels
In an MPLS (multi protocol label switching) enabled network, zero-bandwidth TE (traffic engineering) tunnels can be generated to measure traffic between different routers. By generating a full mesh of tunnels between all pairs of routers, a traffic matrix can be obtained simply by reading the MIB (management information base) traffic counters for the tunnels. A significant difficulty arises when implementing a full mesh of TE tunnels in networks where an SPF (shortest path first) routing scheme is already used. Capacity problems may occur when multiple equal-cost optimal routes exist in the SPF network, and the introduction of the TE tunnels would lead to a different traffic distribution.
Traffic Flow Analysis (TFA)
It is possible to infer traffic flows from interface counters by setting up a model linking the traffic volume through an interface to all flows that are routed through the interface. Unfortunately, this model is under-constrained, so that normally billions of wildly differing possible solutions exist. It is easy to find a solution that is consistent with the observed data, but there is no guarantee that the actual traffic matrix is the same or even related to the one obtained by the model.
This model describing the traffic matrix may be a good starting point for further extensions (called traffic inference (TI)), but on its own is not strong enough to provide reliable results.
LSP Counters
For MPLS-enabled networks, it is possible to collect LSP (label switched path) counter MIBs which provide information about certain aggregated flows in the network. The traffic matrix can be (partially) reconstructed from this information. Data collection across the network may create problems when the number of LSPs is large.
Deduction from SLA
If the SLAs (service level agreements) of the customers are detailed enough, it is possible to deduce an upper bound of the traffic matrix. This not only requires information about the ingress/egress bandwidth for each interface, but also requires information (or assumptions) about the destination of traffic injected from each customer interface. Often, this type of information is not directly available in the SLA. Another problem is that the SLA typically describes peak rates; applying them simultaneously across the network for all customers would lead to a massive overloading of the existing capacity.
Estimation
The traditional method of obtaining a traffic matrix is based on estimation by an experienced network manager. Depending on the knowledge available, this may provide a good picture of the actual traffic. However, without a way of checking against actual measured values, this approach seems limited to rough capacity planning, and many operational issues cannot be addressed.
It is thus desirable to provide an improved way of observing data traffic flow in a network with a view to determining the traffic matrix. The present invention aims to address this problem.